System and method for enabling transactions between a web server and a smart card, telephone, or personal digital assistant over the internet

ABSTRACT

An open network system for supporting input/output (I/O) operations for non-standard I/O devices are disclosed. The system includes a server coupled to a plurality of I/O devices through an open network and an extended open system protocol that supports communication with devices that are not personal computers (PCs). These devices include magnetic stripe readers, check readers, smart card readers, credit card terminals, screen phone terminals, PIN pads, printers, and the like. The extended open network protocol includes tags which identify device and input operations and attributes which identify the location, data exchange method, and data variable names for the retrieval, acquisition, and submission of data between the server and I/O devices. Preferably, the open network protocol is implemented in a Hyper Text Transport Protocol (HTTP).

[0001] This application is a continuation of co-pending application Ser.No. 10/100,347, filed on Mar. 18, 2002, which is a continuation ofapplication Ser. No. 09/907,076, filed on Jul. 17, 2001, which is acontinuation of application Ser. No. 09/314,266, filed on May 18, 1999(now U.S. Pat. No. 6,366,967), which is a continuation of applicationSer. No. 08/995,123 filed Dec. 19, 1997 (now U.S. Pat. No. 5,905,908),which is a continuation of application Ser. No. 08/493,772 filed Jun.22, 1995 (now U.S. Pat. No. 5,742,845).

FIELD OF THE INVENTION

[0002] This invention relates to data transaction systems, and moreparticularly, to data transaction systems using non-standardinput/output devices.

BACKGROUND OF THE INVENTION

[0003] Data transaction systems which communicate with a plurality ofremote terminals to transfer information used to complete a transactionor compile a database are well known. Typically, such systems include acentral transaction processing system which may maintain a database ofinformation such as customer or consumer data. Exemplary information insuch a database may include customer identification, customer accountnumbers, credit limits and/or account balances from which a customer maydraw. The central transaction processing system is typically coupled toa plurality of remote transaction or data input terminals. Transactioncomputers may include special purpose devices such as automatic tellermachines (ATMs), point of sale (POS) terminals, credit card terminals,and screen phone terminals. Screen phone terminals are devices whichintegrate a telephone with an ATM-like device and possibly a magneticcard swipe reader. Data input terminals may include personal computers(PCs) interfaced to data collection devices or special purpose datacollection terminals or monitors.

[0004] In these known data transaction systems, a user usually initiatesa transaction by requesting access to funds in an account or from acredit line maintained by the central processing system. The request istransmitted to the central processing system which performs averification to determine whether the user is a valid user of thesystem, has an account within the system, and that the amount of thetransaction is within the limits of the consumer's credit line or thatthe user has the requested funds available in an existing accountmonitored by the central processing system. The central processingsystem then transmits authorization for or denial of the transaction tothe remote terminal. In response to the message from the centralprocessing system, the remote terminal dispenses cash (for an ATM) orthe merchant provides the goods being purchased to the user if theauthorization message indicates that the consumer's funds will betransferred to the merchant's account. Similar communication exchangesoccur in data systems where electronic documents and other informationare provided to a central site for compilation or processing.Consequently, this background discussion applies to all such transactionand data systems. Though the remainder of the discussion is directed totransaction systems, the reader should appreciate that the comments alsoapply to data systems as well.

[0005] The remote terminals may be coupled to the central processingsystem in several ways. For example, in some ATM systems, the ATNs arecoupled to the central processing system through dedicated telephone orother data communication lines. These systems are preferred because theyprovide a relatively high degree of security since the dedicated dataline coupling the central processing system to the ATM is not generallyaccessible by members of the public. The physical security of thededicated data line is, however, expensive because no other traffic mayutilize the line. Thus, the cost of leasing the dedicated line to an ATMwith relatively low volumes of transactions may yield a highcommunication cost per transaction.

[0006] In an effort to reduce the communication cost per transaction,some transaction or data systems utilize telephone lines through apublicly-switched telephone network (PSTN) which may be accessed byother members of the public. Specifically, devices such as credit cardterminals and screen phone terminals typically include a modem whichconverts the digital messages of the remote terminal into frequencymodulated analog signals which may be transmitted over telephone linesto a modem at the central processing system. In other systems, theterminal may communicate digital data directly over ISDN lines of thePSTN to the central processing system. This line of communicationbetween a remote terminal and the central processing system is performedby having the remote terminal dial a telephone number associated withthe central processing system to establish communication with thecentral processing system. This type of communication path is relativelysecure because the switching networks for the communication trafficthrough the PSTN are not readily accessible by the public and during thecourse of the financial transaction, only the central processing systemand remote terminal are on the line.

[0007] Regardless of the communication method used to couple the centralprocessing system to the remote terminals, the protocol and data formatsused between the devices is typically proprietary. That is, the operatorof each financial transaction system designs its own protocol and datamessage format for communication with the processor at the central siteor generates a variant within a standard such as those established bythe ANSI committee or the like for such communication. As a result, theremote terminals must include software that supports each operator'sprotocol and message formats in order to be compatible with anoperator's central site. For example, application software in a creditterminal such as the TRANZ330, TRANZ380, or OMNI390 manufactured byVeriFone implement one or more of the communication protocols andformats for National Data Corporation (NDC), VISANET, MASTERCARD,BUYPASS, and National Bancard Corporation (NaBANCO) system processors inorder to support transactions with the most popular transaction centers.Thus, the communication software absorbs a significant amount ofterminal resources which could be used to support other terminaloperations.

[0008] A related problem arises from the expanding home banking market.A customer of home banking system typically uses a screen phone terminalor a personal computer (PC) having a modem to establish communicationthrough a PSTN to a central transaction processing system. Again, theoperator of the central processing system must provide informationregarding the data message formats for communicating with the centralprocessing system to a vendor of software for the home banking terminalsor must provide that software to its customers. As a result, homebanking customers must purchase software to communicate with eachbanking system of which the customer wants to be a member. This cost andthe need to install additional communication programs may make someconsumers reluctant to be a member of more than one banking system or tochange banking systems.

[0009] A communication system becoming increasingly popular and whichprovides standardized communication is the Internet. The Internet is anopen network of networks which communicate through a variety of physicalcommunication devices such as telephone lines, direct communicationlines, and the like. Each network is coupled to the main Internetnetwork for communication through a host computer supporting a TCP/IProuter or bridger. The host computer typically includes a program,frequently called a Web server, which acts as a gateway to resources atthe host computer which may be resident on the host computer or anetwork coupled to the host computer. Each server has an addressidentifying the location of the resources available through the Webserver. The router recognizes communication for the server and directsthe message to the server or it recognizes that the communication shouldbe forwarded to another server. As a result, communication within theInternet may be point-to-point, but more likely, the communication pathis a somewhat circuitous one with the information passing through therouters of multiple servers before reaching its final destination.

[0010] A number of message protocols and formats have been developed forthe Internet. The physical communication protocol and data messageformat is the Transport Control Protocol/Internet Protocol (TCP/IP). TheTCP/IP protocol involves multiple layers of encapsulating headerscontaining communication information which are used to provide bytestreams or datagram communications to computers on the networks coupledto the Internet. Encapsulated within TCP/IP headers are protocols whichare used to format the data messages or transfer data from one computerto another computer coupled to the Internet. These protocols includeFile Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), PostOffice Protocol (POP), Telnet, and Hyper Text Transport Protocol (HTTP).The advantage of these protocols is that each provides a standardizedcommunication format for transferring information between computers onthe Internet. These protocols are typically called open system protocolsas they are publicly known and may be utilized by any programmer todevelop programs for communicating with another computer coupled to theInternet. These non-proprietary protocols have contributed to theacceptance of using the Internet as an open network for couplingcomputer networks together.

[0011] While the Internet provides an open network for computercommunication with publicly accessible protocols and formats, theInternet suffers from a number of limitations which preclude itseffective use as a transaction or data system which uses non-standardI/O terminals and devices. First, circuitous communication presents anumber of security issues for such a system For example, a Web servercould incorporate a router which examines the address of each messagecoming through it and upon recognizing an address associated with acentral transaction processing system, copy the data message for theunauthorized retrieval of customer-sensitive information such as accountnumbers and personal identification numbers (PINs) which may becontained in the message.

[0012] A second limitation of open networks such as the Internet is thatcommunication on such networks is only supported for computers acting asservers or clients. Specifically, all of the protocols and formats areconstructed for standard input/output (I/O) operations for a PCterminal. That is, text information is directed to a standard monitorscreen, user input is expected from a standard keyboard, and files aretransferred to standard peripherals such as a hard disk or diskettedrive. Especially absent is the ability in open network protocols forcommunication with devices that only use communication interfaces suchas RS-232C. As a result, communication over the Internet is primarilyperformed with standard PCs through network communication methods andinterfaces.

[0013] This presents a number of problems for home banking or forinterfacing non-standard I/O terminals such as credit card terminals orscreen phones to open networks such as the Internet either directly orthrough a PC. Generally, non-standard I/O devices are devices whichinterface to a PC through a port not normally used for networks, such asa RS-232C port, or are devices which have limited input and outputcapabilities such as small screen displays or ten keypads. These devicesare not supported on the Internet because servers use protocols thatcommunicate with PCs supporting standard QWERTY keyboards and standardmonitors. Consequently, users are limited to entering account numbersand the like through a keyboard of a PC-like device for processing at acentral transaction processing system. To request a transaction, oneneed only have a person's credit card account number. If the credit cardnumber had to be input through a magnetic card reader, unauthorizedaccess to a customer's account would be less likely since physicalpossession of the credit card would be required to initiate thetransaction.

[0014] Another limitation of the standard I/O devices currentlysupported by the open network protocols is the lack of encryption. Forexample, PIN pads, which are typically incorporated in ATMs,automatically encrypt in hardware a PIN entered by a user. Such devicestypically encrypt the number by implementing a data encryption standard(DES) algorithm in hardware before the PIN is transmitted or stored.When a standard keyboard is used to input the PIN, no hardwareencryption is performed and, as a result, an unencrypted copy of the PINis provided to the memory of the PC. Storage of unencrypted PINs is incontravention of current banking regulations. If PIN pads could be readvia Internet protocols, then such a lapse in PIN security would be lesslikely to occur.

[0015] Another I/O device not supported on open networks are smart cardswhich are increasing in use. Smart cards include a processor and memoryin which information regarding the amount of funds in a particularaccount, a transaction history, account numbers, and customer data maybe stored. The card may be read through a smart card reader which is acomputer having a processor and memory but usually provided withnon-QWERTY keypads and limited displays. A transaction processor mayvalidate a card owner through a PIN provided through a keypad, determinethe amount of money remaining on the card and debit the card itself fora transaction amount by communicating with the smart card reader withone of the proprietary protocols discussed above. Such information isnot readily obtainable by the owner of the card and so cannot be enteredthrough a keyboard or the like. Smart card readers are non-standarddevices which may be coupled to a PC through a COMM1 or COMM2 port.However, none of the standard protocols and message formats for opennetwork communications currently provide I/O operations for suchdevices.

[0016] All systems which attempt to provide three party communication toexecute an electronic transaction suffer from a number of limitationswhich present risks greater than those in a normal transaction performedat the point of sale. In a typical point of sale (POS) transaction, theconsumer hands a debit or credit card to a merchant's agent who mayexamine the card for security markings such as holograms, watermarks, ora cardholder signature. The agent then places the card into a reader foracquiring information from the card and, in some cases, have theconsumer enter a PIN into a PIN entry device which encrypts the PIN in ahardware implemented scheme. If the PIN is entered, it is transmittedwith the information from the card to a processing center, typically inone of the formats discussed above, under a X.25 protocol or the like.The processing center returns an authorization granted or deniedmessage. The reader typically has a printer coupled to it through anRS-232C port or the like and a purchase agreement is printed. Theconsumer signs the agreement, the merchant's agent may verify thesignature, and the merchant retains an original of the agreement and theconsumer a copy. In this scenario, the merchant has initiated thecommunication to the processing center. The safeguards noted abovepermit the processing center to charge a merchant a lower processing feethan when a consumer initiates a transaction. Consumer initiatedtransactions present a greater risk because the consumer provides anagent an account number in a telephone conversation or non-encryptedDTMF transmission. Thus, there is no card inspection, signatureverification, or PIN verification. As a result, such transactions arelimited to credit cards because debit cards require that the cardholderbe present to enter a PIN into an appropriate PIN entry device.

[0017] What is needed is a system that permits consumers remote from amerchant to order goods and present payment in a secured manner so themerchant's risk and processing costs, as well as a cardholder's exposureto fraud, is reduced. What is needed is a way for a processing center tocommunicate through an open network with non-standard I/O devices suchas credit card terminals, personal digital assistants, and screen phoneterminals or with non-standard I/O devices coupled to the open networkthrough a PC or the like. What is needed is a transaction or data systemwhich utilizes an open network such as the Internet to supportelectronic transactions or data compilation in a secure manner withoutundue limitation as to the devices with which communication may be made.

SUMMARY OF THE INVENTION

[0018] The present invention provides transaction and data systems whichmay be implemented on an open network such as the Internet. The systemcomprises a server for communicating in an open network protocol and aplurality of input/output (I/O) devices coupled to the server through anopen network, the I/O devices communicating with the server in theextended open network protocol that supports communication withnon-standard I/O devices over the open network. The system of thepresent invention provides a server with the capability of communicatingwith a number of I/O devices useful in transaction and data systemswhich heretofore have been unsupported on an open network system such asthe Internet.

[0019] The system of the present invention is implemented by extendingpresent open network communication protocols and data message formats tocommunicate with non-standard I/O devices either coupled to an opennetwork as a client or coupled to an open network through a client, suchas a PC, credit card terminal, screen phone, or PDA. That is, commandswhich are compatible with the communication schema of apresently-implemented protocol for the Internet are used and additionsare made to commands implemented within the control structure of thatexisting protocol to support non-standard I/O device communication. Atthe server, the extended protocol is further supported by a commongateway interface (CGI) which converts the communication from anon-standard I/O device to a format which is compatible with atransaction or data application program which may be executed on theserver or a computer coupled to the server. In this manner, the CGIpermits the processing of the extended capability commands to besegregated from the communication functions performed by the server.

[0020] Preferably, the server and the I/O devices communicate through anInternet protocol and most preferably, the Hyper Text Transport Protocol(HTTP), to exchange data between an application program and non-standardI/O devices over an open network. Although HTTP is the preferredprotocol used to implement the present invention, other protocols suchas Telnet or SMTP, for example, may also be extended in a similarmanner. Specifically, the HTTP protocol is expanded to communicate withprinters, magnetic card readers, credit card terminals, smart cardreaders, check readers, PIN pads, bar-code readers, PDAs, or the like,and includes a command which instructs a non-standard I/O device todisconnect from the open network and re-couple to a transactionprocessing system to transfer funds from a consumer account to amerchant account through a PSTN or dedicated data line. By using theseextended capability commands within HTTP, a processing system mayoperate on an open network such as the Internet and communicate withtransaction or other data I/O devices which have not previously beenable to couple to such open networks. Such a system may be used toexecute a transaction between a consumer and a merchant so the merchantreceives remittance information in a timely manner. The system permitsthe consumer to initiate a transaction and order from a merchant andthen use a more secure link supported by PIN entry devices or the liketo reduce the risk of fraud for the transaction.

[0021] Because the server may communicate through such open networkswith non-standard I/O devices, the transaction or data processing systemis available for the ever-expanding market available through theInternet. Such a system is able to communicate with non-standard I/Odevices in myriad locations such as retail establishments or inconsumers' homes. For example, a consumer may utilize the standardcapability of an Internet protocol to communicate with a server thatprovides information regarding services or goods for sale over theInternet and then consummate a sales transaction by using the extendedcapability of the Internet protocol. Such a home consumer could providetransaction data through a smart card reader coupled to a COMM1 or COMM2port of a PC. A database program executing at the server for the centralprocessing site may accept product ordering information from anon-standard keypad or touch screen associated with a screen phoneterminal at the remote site and then communicate with the smart cardreader to consummate the transaction. Such a transaction system requiresthat the consumer have physical possession of the smart or credit cardand not simply knowledge of the account number. Likewise, the serverwould be able to communicate with a PIN pad or the like to ensure thehardware encryption of PINs and other data before it is transmitted tothe server site. Such a system is less susceptible to consumer fraud.

[0022] Another feature of the present invention is a PAYMENT commandimplemented in the extended Internet protocol that directs anon-standard I/O device or a PC interfaced with such devices tocommunicate with a transaction processor through an alternativecommunication link. In one form, the PAYMENT command is used by amerchant terminal to submit a consumer's account number with a merchantdeposit account number through a PSTN network or the like to theprocessing center. In another form of the PAYMENT command, a clientprogram in a consumer's terminal receives an account number for amerchant account from a merchant's server with the PAYMENT command. Onreceipt of this command, the client program suspends its operation andpasses the account number to a conventional bank processing programco-resident in memory. The bank processing program establishes astandard communication link with a transaction processing system througha dedicated data line or a PSTN network. Using that communication linkthe bank processing program executes a commercial transaction using astandard VISA protocol or the like. The consumer may use a magneticstripe reader and a PIN entry device to improve the security of the datatransmission. The transaction center may transmit remittance data overthe open network to the merchant so the merchant is apprised of paymentand ships the ordered product. Once this consumer initiated transactionis complete, the bank processing program terminates and returns controlto the client program which may terminate communication with the opennetwork or retrieve information from another server on the open networkfor another transaction. In this way, the user may use the open networkfor non-confidential communication such as collecting productinformation, pricing, and product availability. This information may becollected quickly and efficiently using the extended Internet protocol.The conventional bank processing program and more secure communicationlinks may then be used for the confidential information required for thetransaction. Thus, the present invention is able to combine the featuresand advantages of the Internet with the more secure communication linkand data security enhancing devices of systems presently known.

[0023] Preferably, an editor is provided which permits a user to definean application database table with data fields, define clientapplication data fields, and define the integrated forms forcommunicating data between the defined database tables and a clientapplication. The editor verifies the syntax of the user generatedintegrated forms containing extended Internet protocol statements andclient application statements. The editor ensures that the variablenames for the client application and the data fields for the databaseapplication correspond. Following the generation of the integrated form,the editor parses the integrated form to segregate the database languagestatements from the extended Internet protocol statements. A databaselanguage identifier is substituted in the Internet protocol statementsfor the database statements contained in the integrated form. TheInternet protocol statements are downloaded as a file which isinterpreted by the client program for the collection and submission ofdata from non-standard I/O devices to the database application. Thedatabase language statements segregated from the extended Internetprotocol statements are placed in a second file which is named tocorrespond to the database table defined by the user. The CGIapplication recognizes the database language identifier contained in thereturned forms of the Internet protocol statements. The CGI applicationcorrelates the database identifier with the file previously generated bythe editor which contains the database command statements. Theapplication then inserts the data from the returned form into thedatabase command statements and provides the re-integrated databasecommand statements to the database application. In this manner, thedatabase may be queried by or retrieve data from the non-standard I/Odevice. In the most preferred embodiment, the editor permits a user todevelop integrated forms comprised of the extended HTML language andstandard query language (SQL) database application statements. In thismanner, the user does not have to manually generate the SQL commands,the HTML commands, and carefully correlate the data fields of the twocommands in order to implement a transaction between a client and adatabase.

[0024] These and other advantages and features of the present inventionmay be discerned from reviewing the accompanying drawings and thedetailed description of the invention:

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention may take form in various components andarrangement of components and in various steps and arrangement of steps.The drawings are only for purposes of illustrating a preferredembodiment and are not to be construed as limiting the invention.

[0026]FIG. 1 is a diagram of an open network system in which the presentinvention is utilized;

[0027]FIG. 2 is a diagram of the format of the FORM and INPUT tagsimplemented in the preferred embodiment of the present invention;

[0028]FIG. 3 is a diagram of the preferred SQL commands supported in thepreferred embodiment of the present invention;

[0029]FIG. 4 is a flowchart of the high level processing of the clientprogram which interprets the HTML files of the preferred embodiment ofthe present invention;

[0030]FIG. 5 is a flowchart of the HTML file processing performed by theclient program of the preferred embodiment of the present invention;

[0031]FIG. 6 is a flowchart of the attribute processing for the FORM tagperformed by the client program of the preferred embodiment of thepresent invention;

[0032]FIG. 7 is a flowchart of the processing of the ACTION attributefor the FORM tag performed by the client program of the preferredembodiment of the present invention;

[0033]FIG. 8 is a flowchart of the processing for the METHOD attributefor the FORM tag performed by the client program of the preferredembodiment of the present invention;

[0034]FIG. 9 is a flowchart of the attribute processing for the INPUTtag performed by the client program of the preferred embodiment of thepresent invention;

[0035]FIG. 10 is a flowchart of the processing for the TYPE attributefor the INPUT tag performed by the client program of the preferredembodiment of the present invention;

[0036]FIG. 11 is a flowchart of the processing for the NAME attribute ofthe INPUT tag performed by the client program of the preferredembodiment of the present invention;

[0037]FIG. 12 is a diagram of the format for the ACTION attribute forthe FORM tag performed by the common gateway interface between the Webserver and an application program;

[0038]FIG. 13A is a diagram of the possible communication paths whichmay be used by an I/O device according to the principles of the presentinvention;

[0039]FIG. 13B shows an exemplary FORM tag and INPUT tag for the PAYMENTmethod implemented in a merchant's terminal according to the principlesof the present invention;

[0040]FIG. 13C shows an exemplary FORM tag and INPUT tag for the PAYMENTmethod implemented in a consumer's terminal according to the principlesof the present invention;

[0041]FIG. 14 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMTfiles for the client program and the SQL files for the applicationprogram for a card initiated payment authorization and capturetransaction;

[0042]FIG. 15 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a bar code reader input with card-initiated paymentauthorization transaction;

[0043]FIG. 16 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a key input order with secure payment transaction;

[0044]FIG. 17A shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a smart card debit (Type 1) transaction;

[0045]FIG. 17B shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a smart card debit (Type 2) transaction;

[0046]FIG. 18 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a debit card transaction;

[0047]FIG. 19 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a check verification transaction;

[0048]FIG. 20 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a customer frequency transaction;

[0049]FIG. 21 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for an item search transaction;

[0050]FIG. 22 shows exemplary integrated statements for a file used inthe preferred embodiment of the present invention to generate the HTMLfiles for the client program and the SQL files for tie applicationprogram for retail store end of day reporting;

[0051]FIG. 23 shows exemplary integrated statements for a file used inthe preferred embodiment the present invention to generate the HTMLfiles for the client program and the SQL files for the applicationprogram for a store reporting an e-mail transaction;

[0052]FIG. 24A is a diagram of a manual development process for thefiles interpreted by the client program and the files interpreted by theapplication program in accordance with the principles of the presentinvention; and

[0053]FIG. 24B is a diagram of the generation of the files interpretedby the client program and the files interpreted by application programperformed by an editor constructed in accordance with the principles ofthe present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0054] A transaction or data system constructed in accordance with theprinciples of the present invention is shown is FIG. 1. The system 10includes a Web server. 12 which is coupled to an open network 14 such asthe Internet for communication with various I/O devices and terminals.For example, the I/O devices which may be coupled directly to network 14include standard I/O devices already supported by Internet protocolssuch as PCs 30 and non-standard I/O devices such as a screen phoneterminal 16, a personal digital assistant (PDA) 18, and a credit cardterminal 20. Other exemplary non-standard I/O devices such as smart cardreader 32, personal identification number (PIN) pad 34, magnetic cardswipe reader 36, printer 38, or the like, may be coupled to PCs throughnon-standard I/O ports such as COMM1 and COMM2 ports or to othernon-standard I/O devices such as phone terminal 16, PDA 18, or creditcard terminal 20. Typically, these devices are coupled to PCs or devices16, 18, or 20 through an interface such as a RS-232C interface.Merchants or other vendors may use a Web server 2 to couple to network14 to communicate with the devices and processing system 40.

[0055] The Web server 12 is preferably coupled to a Common GatewayInterface (CGI) application 28 which converts and communicates the dataand commands between the devices on network 14 and the processing system40 so the I/O devices do not have to use the database command languageto interact with the database. System 40 and the devices may communicatedirectly if they are implemented in the same language or if a userimplements a communication interface such as CGI 28 that correlates datafields in the client with those in system 40. Server 12, CGI 28, and theapplications supporting system 40 may all reside on a single hostcomputer or they may reside on separate computers coupled together by alocal area network (LAN) or a wide area network (WAN). Preferably, theapplication interfaces with a database which supports Open Data BaseConnectivity (ODBC) and Structured Query Language (SQL).

[0056] The communication sessions between the I/O devices coupled to theopen network 14 and the Web server 12 are generally conducted in thesame fashion as Internet protocol communication sessions are currentlyperformed. That is, the I/O device establishes a communicationconnection with Web server 12, sends a request to the Web server, theWeb server responds to the request and the I/O device or server closesthe connection. Preferably, the non-standard I/O devices or PCsinterfaced to such devices selectively couple to a local access port onthe open network 14 through a local modem/ISDN connection. In thismanner, the device is only coupled to the open network 14 when atransaction or a data operation is to be performed. While connected tothe open network 14, a device may access a number of servers toaccomplish a purpose. For example, a device may couple to a local accessport and communicate with a first server to check inventory levels at asite, communicate with a second server to order stock for the inventory,and communicate with a third server to settle payment for the orderedgoods. When all aspects of the transaction are complete, the connectionwith the local access port is terminated. In the preferred embodiment ofthe present invention, the protocol used to transport data messagesbetween Web server 12 and the I/O devices coupled to the open network 14is the Hyper Text Transport Protocol (HTML), although other open systemprotocols utilized on the Internet may be used.

[0057] In standard HTTP protocol, a client program executing in one ofthe I/O devices may initiate communication with a server by sending aquery message of the format:

http://<host>:<port>/<path>?<search part>

[0058] The message identifies the client as seeking communication with aHTML server at the host address on the specified port. In the HTMLprotocol, the default value for the port is 80 and the host address isthe Internet protocol (IP) address of the type well-known in the art.The path value selects the file in the HTML server which is activated inresponse to the message and the search part specifies a query for theselected file. In the initial communication, the query may be omitted sothat the selected host file responds to the client program before aquery is processed.

[0059] In the present invention, the client program uses a similarmessage to initiate a transaction or data operation, except thatdatabase commands are preferably embedded in a file at the server 12 andnot in the “search part” of the command, although search parts may beconstructed in accordance with the principles of the present inventionthat support non-standard I/O devices. Preferably, the client programinterprets Hyper Text Markup Language (HTML) files containing HTMLcommands for communicating data between non-standard I/O devices andserver 12. Most preferably, the HTML commands contain identifiers whichare used by the CGI to place data returned in the forms of the HTMLcommands into database commands for queries or data insertions for thedatabase. HTML is a command language well known for the retrieval anddisplay of electronic documents for standard I/O devices such as PCssupported by full screen monitors, QWERTY keyboards, and standardperipherals such as hard disk drives and diskette drives. Standard HTMLcommands use text and previously known commands that reference UniversalResource Locators (URLs) to support the communication of electronicdocuments. These documents are files which may contain HTML commands,text, audio, video, or image data. The present invention extends HTMLwith commands that support communication between the server and thenon-standard I/O devices.

[0060] In the HTTP protocol, data may be obtained during a communicationsession by using a tag called a FORM as part of the file defined by<path> in the command discussed above. The FORM format for standard HTTPis: <FORM ACTION=“URL” METHOD=GET|POST > Command </FORM>

[0061] where “|” is an “OR” operator. The commands supported by standardHTTP are INPUT, SELECT, and TEXTAREA. Additionally, standard HTTPpermits the inclusion of text data in the command area. In the presentinvention, HTML has been extended to support new ACTIONs, METHODs, andINPUTs.

[0062] In accordance with the principles of the present invention, tagsare preferably used to identify device transfers and input operations.Preferably, the FORM tag is used to identify device transfers and ACTIONand METHOD attributes further identify the device operation. As shown inFIG. 2, the extended ACTION field may include a FROM and TO attributefor accessing a local terminal file or smart card reader or a TO PRINTERattribute for directing output data to a printer local to the I/Odevice. The FROM and TO attributes for accessing local files and smartcard readers and for directing output data to a local printer havepreviously been unsupported in any Internet protocol. As a result, theserver 12 may access non-standard I/O peripherals for any of the I/Odevices used in the transaction or data system 10. The ACTION=“URL” is apart of standard HTTP and is well known.

[0063] The METHOD attributes may include the GET, POST, PAYMENT, or SQLmethods. The GET and POST methods are currently supported in standardHTML and are well known. The PAYMENT attribute is a directive to deliverdata retrieved by an INPUT command to a private payment network forauthorization and settlement and is not available in current Internetprotocols. This directive is used by the client program to activate aconventional financial transaction application which communicates withthe transaction system over a dedicated data line or PSTN in a knownprotocol such as VISA. Such an attribute is used where the more securephysical connection between remote site and transaction system and dataencryption devices or the like are preferred. The SQL method preferablyidentifies a database language file which CGI 28 uses to correlate datain the HTML FORM to an insertion or query command contained in the file.

[0064] The preferred format for the INPUT tag which is used to identifyinput operations is also shown in FIG. 2. The TYPE and NAME attributesare used to define a non-standard I/O device or local storage variablefor the input of data. The TYPE field values “text,” “password,”“checkbox,” “radio,” “submit,” and “reset” are previously known, as arethe attributes NAME, VALUE, CHECKED, SIZE, and MAXLENGTH. To support theextended capability of the present invention, the TYPE attributepreferably includes attributes MSRT1 for reading track 1 of a magneticswipe reader, MSRT2 for reading a magnetic swipe reader track 2, KEY forreading input from a terminal command keypad, PIN for reading a personalidentification number pad, BCW for reading a bar code wand, MICR forreading a check magnetic code reader, ATM for reading a dollar amountvia a key input mask, INT for reading an integer via a key input mask,database with the INSERT attribute or update data already existing in adatabase with the UPDATE attribute. The values for the INSERT attributemay be identified with the VALUES attribute, and the SET and WEREattributes may be used to define and conditionally update values in theidentified database. Preferably, the present invention implements twoDELETE and CREATE attributes. The DELETE attribute deletes all items inan identified column of a database table which may satisfy a conditiondefined by a WHERE attribute. The CREATE attribute creates a databasetable having a primary key identified by the PRRIMARY KEY attribute.

[0065] Preferably, the server program executes on a computer systemhaving at least an Intel 80386 or better processor with at least 4megabytes of RAM and at least 3 megabytes of hard disk space available.The computer system running the server may operate any known serverplatform operating system such as WINDOWS 3.1, WINDOWS 95, or WINDOWSNT, UNIX AIX, and others. The non-standard I/O devices require aprocessor of a Z80A type or better, at least 32K bytes of RAM and atleast 32K bytes of ROM. The device includes a modem capable of at least1200 bits-per-second (bps) but other modem speeds may be used forcommunication between client and server. Alternatively, the device maybe coupled to a LAN which in turn is coupled to the Internet forcommunication with server 12. A typical non-standard device whichexecutes the client program is a VeriFone OMNI390, ON395, or VuFoneterminal. OMNI390, OMNI395, and VuFone are trademarks of VeriFone, Inc.,of Redwood City, Calif. Other exemplary devices include Phillips Screenphone, Hypercomm T7 terminal, and Apple Computer Newton MessagePad.

[0066] To build the preferred HTML files which CGI 28 preferably uses toimplement the client program and database application, the userpreferably uses an off-line editor. The files generated by the editorare preferably comprised of an integrated statements formed from HTMLstatements and database statements for retrieving and writing data withthe database. Exemplary files showing such integrated statements forperforming transactions are depicted in FIGS. 14-23B. After such a fileis generated, the editor parses the integrated statements into HTMLstatements and into database statements such as SQL commands. The HTMLfiles required by the client program to support communication with atransaction or data processing center may be downloaded to a device orPC for execution. The files containing the database applicationstatements used by the CGI interface to communicate data with thedatabase application program preferably reside on server 12. Preferably,the database files used by the CGI interface include SQL commands forthe application program interfaced to an ODBC compliant database.

[0067] The general format of the HTML commands in the HTML files usedfor communication with a client program and server are of the generalformat: TAG ATTRIBUTE. Preferably, the TAG field may be one of FORM,INPUT, SQL, or TEXTAREA. The ATTRIBUTE field value depends upon the TAGvalue. Preferably, the FORM tag may include the ACTION or METHODattributes where the ACTION attributes include the FROM<file>, TOPRINTER TO<file>, and TO SCR values noted above, as well as the standardHTML ACTION value of URL=<file>. The METHOD attributes include thePAYMENT and SQL attributes noted above, as well as the standard HTMLMETHOD values of GET and POST. Also in accordance with the principles ofthe present invention, the INPUT tag may include TYPE, NAME, VALUE,CHECKED, SIZE, and MAXLENGTH attributes. These attributes are previouslysupported for the INPUT tag in HTML, however, the present inventionfurther includes TYPE values of MSRT1, MSRT2, KEY, PIN, BCW, MICR, AMT,INT, LOCAL, and AUTOSUB, as well as the standard HTML TYPE values ofTEXT, PASSWORD, CHECKBOX, RADIO BUTTON, SUBMIT, and RESET. The presentinvention also supports NAME attributes of IP_ADDRESS, HOST_PHONE, TID,WORK_KEY, DATETIME, and DEPOSIT_ACCT to identify local storage areas aswell as standard HTML NAME attribute <Field_NM> to identify a FORMvariable.

[0068] The preferred high level processing of the client program isshown in FIG. 4. That processing includes an idle step (Block 100) inwhich the program performs general housekeeping tasks such asmaintaining internal time, scanning for input which may activate thedevice, or other known functions. Further processing is activated bysome operator action at the device or PC which causes the device toeither open a remote URL (Block 102) or open a local URL (Block 104). Ifa remote URL is required, the device transmits a message of the formatdiscussed previously which is routed through the open network anddelivered to a server 12 for a transaction or data processing system(Block 106). The HTML file selected at the server 12 is identified bythe remote URL in the initial communication between the device andserver 12 and that URL is used to return the selected HTML file to thedevice for processing (Blocks 108, 110).

[0069]FIG. 4 also shows that an operator may initiate an open local URLfunction by typing in a command or by pushing a hot key which isassociated with a local URL. The I/O device reads the HTML fileidentified by the URL from local memory (Block 112) and passes the HTMLfile to the function for processing HTML files (Block 110). After a fileis processed (Block 110), the client program determines whether the HTMLfile is to be stored (Block 114). If it is not, the process returns tothe idle processing (Block 100). Otherwise, the process determineswhether the HTML file is to be associated with a hot key (Block 116)and, if it is, it stores the file and generates the link between a hotkey and the stored file (Blocks 118, 120). If the HTML file is only tobe stored, no association is made with a hot key and the file is simplystored in local memory (Block 20). The client program then returns toidle processing (Block 100).

[0070] The high-level processing for the HTML file (Block 110, FIG. 4)is shown in further detail in FIG. 5. The process begins by scanning theHTML file for a TAG (Block 140). If no TAG is found, the file is not inproper format for processing and processing returns to Block 114discussed in FIG. 4 above. If a TAG is found (Block 142), the processdetermines whether the TAG is a FORM TAG (Block 144) or an INPUT TAG(Block 146). If it is a FORM TAG, then the FORM TAG is processed and theprogram continues by looking for other TAGS to process (Block 140). Ifthe TAG is an INPUT TAG, the INPUT TAG is processed (Block 150) and theprogram continues by looking for other TAGS to process (Block 140). Ifthe TAG is one of the standard HTML TAGS, the program implements the TAGin standard known ways. (Block 152) and then scans for other TAGs toprocess (Block 140).

[0071] Processing the ATTRIBUTES used to implement a FORM TAG is shownin FIG. 6. That process continues by scanning the HTML file for anattribute (Block 160). If an attribute is not found (Block 162), theprogram returns to scan for other TAGS (Block 140, FIG. 5). If anattribute is found, the program determines whether it is an ACTIONattribute (Block 164) or a METHOD attribute (Block 166). Depending onthe type of attribute, the appropriate function for processing theattribute is executed (Blocks 168 or 170) and scanning for additionalattributes continues (Block 160). If the attribute is not an ACTION orMETHOD attribute, there is an error in the file and processing returnsto scan for other TAGs.

[0072] The processing for the ACTION attribute is shown in FIG. 7.There, the ACTION attribute is examined to determine whether it is aFROM<file> (Block 180), TO PRINTER (Block 182), TO<file> (Block 184), TOSCR (Block 186), FROM SCR (Block 188) or a URL=<file> (Block 192). TheURL=<file> ACTION is a standard HTML action which is processed in aknown way (Block 194). The FROM <file> action is processed by readingdata from a file associated with the I/O device or PC interfaced to theI/O device (Block 196). The TO PRINTER action results in data in theFORM being sent to the printer (Block 198) while the TO <file> actionresults in data in the FORM being written to a local file (Block 200).The TO SCR action causes data to be written to the smart card via asmart card reader (Block 202) and the FROM SCR reads data from a smartcard through a smart card reader (Block 204). After the appropriateaction processing takes place, the HTML file is scanned for additionalACTION values to perform (Block 206), and if one is found, the processcontinues. If no attribute is located (Block 208), the process returnsto scan for other attributes (Block 160, FIG. 6).

[0073] The processing for the METHOD attributes for FORM tags are shownin FIG. 8. The process determines which type of METHOD is present in theFORM and then properly processes the attribute. For the GET and POSTmethods (Blocks 210, 212) the processing is the same as that performedin standard HTML (Blocks 226, 228). That is, for the GET method, theidentified URL<file> is queried for data while the POST attribute causesdata to be transferred to the URL<file>. The preferred METHOD attributesextending the HTML implementation of the present invention are SQL(Block 214), and PAYMENT (Block 224) attributes. The SQL attribute ispreferably not expanded into a SQL command at the client, but rather isexpanded by the CGI 28 at server 12 by correlating the data or variablefield names in a returned form with the SQL commands stored at theserver. This processing is done in a manner described in more detailbelow. The client program passes the SQL file identifier to the server12 (Block 230). The processing of the PAYMENT command (Block 232) isdiscussed in more detail below. The HTML file is scanned for otherMETHODs (Block 242, 244), and, if one is found, the processing continuesby identifying the METHOD (Blocks 210-224). Otherwise (Block 244), theprocess returns to scan the HTML file for other ACTION or METHODattributes (Block 160, FIG. 6).

[0074] Processing for the INPUT tag is shown in FIG. 9. The processscans the HTML file following the INPUT tag for attributes (Block 250).If no attributes are found (Block 252), the process continues byscanning the HTML file for other tags to process (Block 140, FIG. 5). Ifan attribute is found and it is a TYPE attribute (Block 254), it isprocessed (Block 256), and if the attribute is a NAME attribute (Block258), it is processed (Block 260). Both the TYPE and NAME processing isshown in more detail in FIGS. 10 and 11, respectively. If the attributeis neither a NAME or TYPE attribute, it is a standard attribute for anINPUT tag supported by standard HTML and is processed in a known manner(Block 262). Following processing of the INPUT attribute, the HTML fileis scanned for other attributes to process (Block 250).

[0075] Processing for the TYPE attribute is shown in FIG. 10. Theprocess first identifies the TYPE attribute for the INPUT tag and thenperforms the appropriate processing. The new TYPE attributes of thepreferred embodiment of the present invention are MSRT1 (Block 270),MSRT2 (Block 272), KEY (Block 274), PIN (Block 276), BCW (Block 278),MICR (Block 280), AMT (Block 282), INT (Block 284), LOCAL (Block 286),and AUTOSUB (Block 288). If the TYPE attribute is not one of these, itis a standard HTML type attribute that is processed in a known manner(Block 310). Each of the new HTML TYPES supported by the presentinvention causes an I/O operation with a non-standard device.Specifically, these operations are the reading of Track 1 of themagnetic stripe reader (Block 290), the reading of the second track ofthe magnetic stripe reader (Block 292), the reading of a keypad (Block294), the reading of an encrypted PIN through a PIN entry device (Block296), the reading of a bar code through a bar code reader (Block 298),the reading of encoded data on a check through a magnetic check reader(Block 300), the reading of a dollar amount from a keypad through a keyinput mask (Block 302), the reading of a number from a keypad through akey input mask clock 304), the reading of data from a local variable(Block 306). and the submission of the data read from one of thesedevices in a FORM returned to the server 12 (Block 308). The data maskfor AMT constrains the dollar amount read to a predetermined number ofcharacters with only two characters following the decimal point. Thedata mask for INT ensures the number is an integer value within apredetermined range. Processing continues by scanning the HTML file forother TYPE attributes (Block 312) and, if another TYPE attribute isfound (Block 314), processing continues by determining the TYPEattribute and performing the appropriate processing. Otherwise, theprocess returns to scan the HTML file for other attributes (Block 250,FIG. 9).

[0076] The NAME attribute processing is performed in accordance with theprocess shown in FIG. 11. That process examines the NAME attribute todetermine if the variable name identified by the attribute isIP_ADDRESS, HOST_PHONE, TID, WORK_KEY, DATETIME, or DEPOSIT_ACCT (Blocks320, 322, 324, 326, 328, 330). If they are, the INPUT value resultingfrom one of the INPUTS in a FORM of the HTML file is stored in a localvariable identified by the NAME attribute. Following storage (Block332), the file is scanned for other NAME attributes (Block 328) and, ifthere are none (Block 332), processing continues by scanning for otherattributes for the INPUT tag (Block 250, FIG. 9). If the NAME attributeis a standard HTML INPUT NAME, it is processed by known methods (Block336). Processing then continues by scanning for other NAME attributes toprocess (Block 338, 340). Otherwise, the process returns to scan theHTML file for other attributes (Block 250, FIG. 9).

[0077] CGI 28 receives Internet protocol statements in a filetransmitted from a client program and provides data from thosestatements to the application(s) implementing system 40 and receives theoutput of system 40 and provides them to the client program in a file.CGI 28 may be implemented by a program developed by a user using amanual development method as shown in FIG. 24A. That method requires auser to generate a system definition from which a file statementdefinition for the client and application are developed to implement thetransactional or data system. Using the file statement definitions, theuser generates the files for the client and database programs which areinterpreted by the respective programs to implement transactions or dataprocessing. This process requires the user to not only have knowledgeregarding the transaction or data process but specific details of theinteraction between the client and database. The user is furtherrequired to resolve and correlate all data identifiers in the statementsfor the client and database environments.

[0078] Preferably, CGI 28 is developed with an editor that only requiresthe user to define the system with statements which are an integrationof the protocol statements and the database language. The processimplemented by this editor is shown in FIG. 24B. Examples of suchintegrated statements for files which implement a specific transactionare shown in FIGS. 14 to 23B. The editor verifies the syntax of theintegrated statements and correlates the data variables of the protocolstatements with the data fields of the database. Following thegeneration of the integrated statements, the editor segregates theprotocol statements from the database language statements. The protocolstatements are stored in files which are identified as being for aparticular transaction or data process and the database statements arestored in files which are identified as being for a particulartransaction or data process on an identified database table. The editorplaces a database file identifier in the protocol statements whichcontained embedded database statements. The database file identifiersare used by CGI 28 to select the file for the appropriate transaction soCGI 28 may correlate data variables in the protocol statements with datafields in the database files. The files containing statements to beinterpreted by the client program are then downloaded to the appropriateterminals, and the database files containing database languagestatements are stored on the system executing the CGI 28.

[0079] Alternatively, the editor of the present invention may parseintegrated statements which are segregated into source code statementsfor first and second processors, such an editor further includes acompiler to generate executable code for each processor and, if theprocessors execute differing source code, a compiler for each sourcecode language. The executable code may then be downloaded to therespective processors for execution.

[0080] More specifically, the editor preferably places the databasestatements for one of the transactions of the preferred embodiment in afile identified by the database name following SQL in FIG. 12. Theattributes and tags forming the HTML statements for one of thetransactions of the preferred embodiment are placed in a file generallydenoted as <html_file>.HTML. The name <html_file> is a name whichidentifies one of the transactions. Where SQL statements are in thefields of the integrated statements shown in FIGS. 14 to 23B, the string“<html_file>.SQL” is substituted as the database name in the statementsof the <html_file>.HTML file. When the CGI executable file is initiatedand parses the returning forms, the returned data is placed in thecorresponding “<html_file>.SQL” file which is passed to the applicationprogram as a command line argument. In this manner, an abbreviated formfor the SQL commands may be communicated over the open network betweenthe client and CGI and the CGI may be able to expand those abbreviatedSQL commands into the appropriate SQL commands which the applicationprogram requires to manipulate the ODBC database.

[0081] To effectuate a transaction, for example, an operation at aterminal with non-standard I/O devices may activate a terminal file witha hot key or other action. In processing the activated file, the clientprogram may acquire data which is stored in a local variable oraccessible through a non-standard I/O device. This data may then bestored in a FORM and submitted to a server file at a processing systemaddress. The server file activates CGI 28 which retrieves data from theFORM and incorporates it into database statements in the database filefor the appropriate transaction and database. If the database statementis a query, the requested data is returned to the CGI in the databasefile and the CGI places it in the corresponding FORM variables so theserver may return the data to the terminal. If the database statementprovides data to a database to obtain an authorization, for example, theaction performed by the database application in response to the data isplaced in the corresponding FORM and returned to the terminal. In thisway, data is exchanged between the terminal and the databaseapplication. This exchange is supported by CGI 28 even though theserver/client communication is performed in an open system protocol,such as HTTP, and the database application is performed in anotherlanguage, such as SQL. CGI 28 is able to convert and exchange the databetween the client and database without the user having to specificallydesign and implement a conversion program.

[0082] The communication paths available for a device implementing thepresent invention are shown in FIG. 13A. As shown there, an I/O device420 is coupled through the Worldwide Web open network 426 to an InternetWeb server 12. This connection may be implemented with the preferredextended capability HTML described above. Although HTML files may beencrypted to enhance the security of the document as it is communicatedacross the Internet, the operator of the system may choose to utilize amore secure physical connection between the device 420 and the Webserver 12. To obtain this alternative connection, the PAYMENT commandfor the METHOD attribute is preferably used. One form of the PAYMENTcommand is for a merchant's terminal and the other is for a consumer'sterminal. In either terminal, the client program which supports theextended capability HTML operates independently but co-resident inmemory with a certified bank card authorization and capture application,which may be provided by a financial institution or a bank cardprocessor.

[0083] For the form of the command shown in FIG. 13B, the client programin the merchant terminal suspends its execution and passes the terminalidentifier, stored locally, which identifies the merchant's account andthe consumer account information read via a magnetic stripe reader orthe like, to the bank card application. The bank card applicationcommunicates this information via a PSTN 424 or the like to atransaction processor 422. The processor 422 authorizes or denies thetransaction and, if authorized, a printer at the merchant terminalprints a purchase agreement which the consumer may execute to completethe transaction.

[0084] In response to a HTML file having a FORM with an ACTION attributeequal to an executable file name for a bank card application program orthe like, a METHOD attribute with a field value of PAYMENT, and an INPUTtag with a TYPE attribute of LOCAL_NAME which identifies a deposit onlyaccount supplied by a merchant (as shown in FIG. 13C), the clientprogram is suspended and control is transferred to the bank processingapplication. The bank processing application then uses a modem or ISDN Dchannel using T3 POS protocol or the like to connect to a secure packetnetwork 424 to connect in a virtual point-to-point manner with a paymentprocessor through a PSTN network or the like. This physical connectionprovides an additional security element to the encrypted data for thetransaction of account information, PIN numbers encrypted by PIN padsprovided at the consumer site, and other sensitive information. The bankprocessor 422 may submit remittance data to the merchant, via the Web orotherwise. After receiving the remittance data, the merchant may shipthe product to the consumer. Thus, in this manner, the I/O device maycommunicate with a plurality of Web servers to “shop” for a best price,delivery date, or other relevant information for selecting a preferredtransaction, and then execute the PAYMENT method to utilize a moresecure physical communication connection and data security devices toconsummate the financial elements of the transaction with less risk andcosts for the merchant, consumer, and bank processor.

[0085] The preferred integrated HTML/SQL statements which support a cardinitiated payment authorization and capture transaction are shown inFIG. 14. A first file 500 includes statements which identify the URLdatabase from which the non-standard I/O device seeks authorization fora transaction. The prompts to the operator to enter the account numberand amount of the transaction are supported by the INPUT tags which readthe second track of the magnetic stripe reader to accept a number of upto 40 characters and assign that information from that track to avariable, and to input the up to 8 characters from the keyboard or thelike into a variable called AMOUNT. The INPUT tag with the TYPEattribute of AUTOSUBMIT returns the form to the server for processing inaccordance with the method defined in the returned form. As shown inFIG. 14, that METHOD statement causes CGI 28 to incorporate returneddata into SQL commands which query the database as to whether thesubfield of the track 2 data representing the account number is presentin the authorization table of the database. If the data is not present,then a new record is inserted into a table labeled “log_table”. The newrecord consists of the account number and the amount returned in theFORM. Based upon the results of this processing, the application programsupplies the data fields to the FORM which will be returned to theclient program for printing the transaction record. That file 510 isshown in FIG. 14. The ACTION attribute TO PRINTER and the POST METHODcauses the data in the next eight lines to be directed to the printercoupled to the non-standard I/O device for printing the transactionform. The customer may then execute the printed form to complete thetransaction. If the transaction is declined or an error is otherwiseencountered, the file 520 is used to return a denial to the clientprogram.

[0086] In a similar manner, the preferred integrated statements for abar code order input with card-initiated payment authorization is shownin FIG. 15. The file 550, supported by the present invention whichimplements the transaction request, is again directed to the properdatabase by the ACTION attribute. The necessary customer informationsuch as name and address may be input through a standard keyboard. TheHTML command in the present invention also permits the form to receivethe bar code, unit price, and credit card information in a mannersimilar to that discussed above for the magnetic card reader. Once thisinformation is returned to the server and CGI interface, it is processedby the application program in accordance with the METHOD identified inthe returned form. The method of HTML file 550 also creates a databaseorder_table having the information shown in the method. Again, if thetransaction is approved, the data for the order and customer acceptanceof the order is provided in HTML file 555, which is directed by theACTION attribute to the printer at the non-standard I/O device. If theaccount number is not in the authorization database, the authorizationdeclined or error response is provided in correspondence with thestatements in file 560.

[0087] In a similar manner, FIGS. 16-22 show the integrated statementsfor a transaction request, authorization response, or authorizationdeclined response files for key input order with secure paymenttransaction (FIG. 16), a smart card-debit (Type 1) transaction (FIG.17A), a smart card debit (Type 2) transaction (FIG. 17B), a debit cardtransaction (FIG. 18), a check verification transaction (FIG. 19), acustomer frequency transaction (FIG. 20), an item search transaction forwhich there is no denial (FIG. 21), retail store end of day reporting(FIG. 22) and a store reporting an e-mail transaction (FIG. 23).

[0088] While the present invention has been illustrated by thedescription of a preferred and alternative embodiments and processes,and while the preferred and alternative embodiments and processes havebeen described in considerable detail, it is not the intention of theapplicant to restrict or in any way limit the scope of the appendedclaims to such detail. Additional advantages and modifications willreadily appear to those skilled in the art. For example, rather thanexpanding HTTP to support non-standard I/O devices, the FTP, POP, SMTP,TELNET or other protocols may be expanded in like manner to couplenon-standard I/O devices to the Internet. Similarly, the preferredimplementation of the present invention supports a variety ofnon-standard I/O devices and I/O operations. An Internet protocol may beconstructed in accordance with the principles of the present inventionto support only selected I/O devices or operations disclosed in thepresent application. The invention in its broadest aspects is thereforenot limited to the specific details, preferred embodiment, andillustrative examples shown and described. Accordingly, departures maybe made from such details without departing from the spirit or scope ofapplicant's general inventive concept.

1. A Internet processing system comprising: a Web server forcommunicating in an extended Internet protocol; and a plurality ofinput/output (I/O) devices coupled to the Web server through theInternet, the I/O devices communicating with the Web server in theextended Internet protocol that supports communication with non-standardI/O devices; wherein the extended Internet protocol further comprising:tags for identifying one of the I/O devices and input operation to beperformed with the one of the I/O devices; action attributes fordefining the identified device operation to be performed with a localresource for one of the I/O devices; and method attributes for defininga data transfer method for providing data between the Web server and theI/O devices.
 2. A Internet processing system comprising: a Web serverprogram coupled to the Internet; a smart card coupled to the Internet;and a client program for communicating data in an extended Internetprotocol between the Web server program and the smart card, the extendedInternet protocol including one identifier for the smart card for atransaction and an identifier for an operation to be performed with theidentified smart card.
 3. A method for processing data over the Internetfor a smart card comprising: coupling a Web server to the Internet;coupling a smart card to the Internet; communicating data conforming toan extended Internet protocol between the Web server program and thesmart card; identifying the smart card in a protocol statementconforming to the extended Internet protocol; and identifying anoperation to be performed with the identified smart card.
 4. An Internetprocessing system comprising: a Web server program coupled to theInternet, the Web server program including a common gateway interface; asmart card coupled to the Internet; a client program for communicatingdata in an extended Internet protocol between the Web server program andthe smart card, the client program communicating the data in fileshaving protocol statements conforming to the extended Internet protocol;and the common gateway interface providing data from the protocolstatements conforming to the extended Internet protocol to a transactionsystem, correlates data in the protocol statements conforming to theextended Internet protocol with data fields in database files for adatabase coupled to the Web server, and receives data from thetransaction system to provide the data to the client program.
 5. Amethod for processing data over the Internet for a smart cardcomprising: coupling a Web server program to the Internet; coupling asmart card to the Internet; communicating data conforming to an extendedInternet protocol between the Web server program and the smart card;coupling a common gateway interface to the Web server program, thecommon gateway for communicating data between a database and the Webserver program; providing data from protocol statements conforming tothe extended network protocol to a transaction system, the protocolstatements being received in a file from the client program; receivingdata from the transaction system and providing the data to the clientprogram in a file; and correlating data in extended Internet protocolstatements with data fields in database files.
 6. A method forcommunicating between a client program controlling a smart card and aWeb server over the Internet comprising: activating a smart card toassign data obtained by the smart card to a variable name in a filecomprised of extended Internet protocol statements; and sending a filehaving the assigned data to a Web server to perform a data operation inaccordance with the extended Internet protocol statements.
 7. A methodfor communicating between a client program controlling a smart card anda Web server over the Internet comprising: generating a file comprisingextended Internet protocol statements, at least one of which identifiesa data operation for obtaining data from a smart card; and sending thefile to a client program controlling the smart card.
 8. A system forcommunicating between a client program controlling a smart card and aWeb server over the Internet comprising: means for generating a filecomprising extended Internet protocol statements, at least one of whichidentifies a data operation for obtaining data from a smart card; andmeans for sending the file to a client program controlling the smartcard.
 9. A Internet processing system comprising: a Web server programcoupled to the Internet; a telephone coupled to the Internet; and aclient program for communicating data in an extended Internet protocolbetween the Web server program and the telephone, the extended networkprotocol including one identifier for the telephone for a transactionand an identifier for an operation to be performed with the identifiedtelephone.
 10. A method for processing data over the Internet for atelephone comprising: coupling a Web server to the Internet; coupling atelephone to the Internet; communicating data conforming to an extendedInternet protocol between the Web server program and the telephone;identifying the telephone in a protocol statement conforming to theextended network protocol; and identifying an operation to be performedwith the identified telephone.
 11. An Internet processing systemcomprising: a Web server program coupled to the Internet, the Web serverprogram including a common gateway interface; a telephone coupled to theInternet; a client program for communicating data in an extendedInternet protocol between the Web server program and the telephone, theclient program communicating the data in files having protocolstatements conforming to the extended Internet protocol; and the commongateway interface provides data from the protocol statements conformingto the extended Internet protocol to a transaction system, correlatesdata in the protocol statements conforming to the extended Internetprotocol with data fields in database files for a database coupled tothe Web server, and receives data from the transaction system to providethe data to the client program.
 12. A method for processing data overthe Internet for a telephone comprising: coupling a Web server programto the Internet; coupling a telephone to the Internet; communicatingdata conforming to an extended Internet protocol between the Web serverprogram and the telephone; coupling a common gateway interface to theWeb server program, the common gateway for communicating data between adatabase and the Web server program; providing data from protocolstatements conforming to the extended network protocol to a transactionsystem, the protocol statements being received in a file from the clientprogram; receiving data from the transaction system and providing thedata to the client program in a file; and correlating data in extendedInternet protocol statements with data fields in database files.
 13. Amethod for communicating between a client program controlling atelephone and a Web server over the Internet comprising: activating atelephone to assign data obtained by the telephone to a variable name ina file comprised of extended Internet protocol statements; and sending afile having the assigned data to a Web server to perform a dataoperation in accordance with the extended Internet protocol statements.14. A method for communicating between a client program controlling atelephone and a Web server over the Internet comprising: generating afile comprising extended Internet protocol statements, at least one ofwhich identifies a data operation for obtaining data from a telephone;and sending the file to a client program controlling the telephone. 15.A system for communicating between a client program controlling atelephone and a Web server over the Internet comprising: means forgenerating a file comprising extended Internet protocol statements, atleast one of which identifies a data operation for obtaining data from atelephone; and means for sending the file to a client programcontrolling the telephone.
 16. A Internet processing system comprising:a Web server program coupled to the Internet; a personal digitalassistant (PDA) coupled to the Internet; and a client program forcommunicating data in an extended Internet protocol between the Webserver program and the personal digital assistant (PDA), the extendedInternet protocol including one identifier for the personal digitalassistant (PDA) for a transaction and an identifier for an operation tobe performed with the identified personal digital assistant (PDA).
 17. Amethod for processing data over the Internet for a personal digitalassistant (PDA) comprising: coupling a Web server to the Internet;coupling a personal digital assistant (PDA) to the Internet;communicating data conforming to an extended Internet protocol betweenthe Web server program and the personal digital assistant (PDA);identifying the personal digital assistant (PDA) in a protocol statementconforming to the extended Internet protocol; and identifying anoperation to be performed with the identified personal digital assistant(PDA).
 18. An Internet processing system comprising: a Web serverprogram coupled to the Internet, the Web server program including acommon gateway interface; a personal digital assistant (PDA) coupled tothe Internet; a client program for communicating data in an extendedInternet protocol between the Web server program and the personaldigital assistant (PDA), the client program communicating the data infiles having protocol statements conforming to the extended Internetprotocol; and the common gateway interface provides data from theprotocol statements conforming to the extended Internet protocol to atransaction system, correlates data in the protocol statementsconforming to the extended Internet protocol with data fields indatabase files for a database coupled to the Web server, and receivesdata from the transaction system to provide the data to the clientprogram.
 19. A method for processing data over the Internet for apersonal digital assistant (PDA) comprising: coupling a Web serverprogram to the Internet; coupling a personal digital assistant (PDA) tothe Internet; communicating data conforming to an extended Internetprotocol between the Web server program and the personal digitalassistant (PDA); coupling a common gateway interface to the Web serverprogram, the common gateway for communicating data between a databaseand the Web server program; providing data from protocol statementsconforming to the extended Internet protocol to a transaction system,the protocol statements being received in a file from the clientprogram; receiving data from the transaction system and providing thedata to the client program in a file; and correlating data in extendedInternet protocol statements with data fields in database files.
 20. Amethod for communicating between a client program controlling a personaldigital assistant (PDA) and a Web server over the Internet comprising:activating a personal digital assistant (PDA) to assign data obtained bythe personal digital assistant (PDA) to a variable name in a filecomprised of extended Internet protocol statements; and sending a filehaving the assigned data to a Web server to perform a data operation inaccordance with the extended Internet protocol statements.
 21. A methodfor communicating between a client program controlling a personaldigital assistant (PDA) and a Web server over the Internet comprising:generating a file comprising extended Internet protocol statements, atleast one of which identifies a data operation for obtaining data from apersonal digital assistant (PDA); and sending the file to a clientprogram controlling the personal digital assistant (PDA).
 22. A systemfor communicating between a client program controlling a personaldigital assistant (PDA) and a Web server over the Internet comprising:means for generating a file comprising extended Internet protocolstatements, at least one of which identifies a data operation forobtaining data from a personal digital assistant (PDA); and means forsending the file to a client program controlling the personal digitalassistant (PDA).
 23. A system for supporting communication between a Webserver and a smart card over the Internet comprising: a Web server thatprocesses extended Internet protocol statements, the Web server beingcommunicatively coupled to the Internet; a smart card communicativelycoupled to the Internet; and a client program for processing extendedInternet protocol statements so that the smart card may communicate withthe Web server.
 24. The method of claim 23 wherein the extended Internetprotocol statements are extended Hyper Text Transport Protocol (HTTP)statements.
 25. The method of claim 23 wherein the extended Internetprotocol statements are extended Hyper Text Markup Language (HTML)command statements.
 26. A client program for processing extendedInternet protocol statements so a smart card may communicate with a Webserver over the Internet comprising: means for receiving extendedInternet protocol statements over the Internet; and means for processingthe received extended Internet protocol statements to control operationsassociated with a smart card.
 27. The method of claim 26 wherein theextended Internet protocol statements are extended Hyper Text TransportProtocol (HTTP) statements.
 28. The method of claim 26 wherein theextended Internet protocol statements are extended Hyper Text MarkupLanguage (HTML) command statements.
 29. A method for supportingcommunication between a Web server and a smart card over the Internetcomprising: processing extended Internet protocol statements at a Webserver communicatively coupled to the Internet; communicatively couplinga smart card to the Internet; and processing extended Internet protocolstatements with a client program so that the smart card may communicatewith the Web server.
 30. The method of claim 29 wherein the extendedInternet protocol statements are extended Hyper Text Transport Protocol(HTTP) statements.
 31. The method of claim 29 wherein the extendedInternet protocol statements are extended Hyper Text Markup Language(HTML) command statements.
 32. A method for processing extended Internetprotocol statements so a smart card may communicate with a Web serverover the Internet comprising: receiving extended Internet protocolstatements over the Internet; and processing the received extendedInternet statements to control an operation associated with a smartcard.
 33. The method of claim 32 wherein the extended Internet protocolstatements are extended Hyper Text Transport Protocol (HTTP) statements.34. The method of claim 32 wherein the extended Internet protocolstatements are extended Hyper Text Markup Language (HTML) commandstatements.
 35. A system for supporting communication between a Webserver and a telephone over the Internet comprising: a Web server thatprocesses extended Internet protocol statements, the Web server beingcommunicatively coupled to the Internet; a telephone communicativelycoupled to the Internet; and a client program for processing extendedInternet protocol statements so that the telephone may communicate withthe Web server.
 36. The method of claim 35 wherein the extended Internetprotocol statements are extended Hyper Text Transport Protocol (HTTP)statements.
 37. The method of claim 35 wherein the extended Internetprotocol statements are extended Hyper Text Markup Language (HTML)command statements.
 38. A client program for processing extendedInternet protocol statements so a telephone may communicate with a Webserver over the Internet comprising: means for receiving extendedInternet protocol statements over the Internet; and means for processingthe received extended Internet protocol statements to control operationsassociated with a telephone.
 39. The method of claim 38 wherein theextended Internet protocol statements are extended Hyper Text TransportProtocol (HTTP) statements.
 40. The method of claim 38 wherein theextended Internet protocol statements are extended Hyper Text MarkupLanguage (HTML) command statements.
 41. A method for supportingcommunication between a Web server and a telephone over the Internetcomprising: processing extended Internet protocol statements at a Webserver communicatively coupled to the Internet; communicatively couplinga telephone to the Internet; and processing extended Internet protocolstatements with a client program so that the telephone may communicatewith the Web server.
 42. A method for processing extended Internetprotocol statements so a telephone may communicate with a Web serverover the Internet comprising: receiving extended Internet protocolstatements over the Internet; and processing the received extendedInternet statements to control an operation associated with a telephone.43. The method of claim 42 wherein the extended Internet protocolstatements are extended Hyper Text Transport Protocol (HTTP) statements.44. The method of claim 42 wherein the extended Internet protocolstatements are extended Hyper Text Markup Language (HTML) commandstatements.
 45. A system for supporting communication between a Webserver and a personal digital assistant (PDA) over the Internetcomprising: a Web server that processes extended Internet protocolstatements, the Web server being communicatively coupled to theInternet; a personal digital assistant (PDA) communicatively coupled tothe Internet; and a client program for processing extended Internetprotocol statements so that the personal digital assistant (PDA) maycommunicate with the Web server.
 46. The method of claim 45 wherein theextended Internet protocol statements are extended Hyper Text TransportProtocol (HTTP) statements.
 47. The method of claim 45 wherein theextended Internet protocol statements are extended Hyper Text MarkupLanguage (HTML) command statements.
 48. A client program for processingextended Internet protocol, statements so a personal digital assistant(PDA) may communicate with a Web server over the Internet comprising:means for receiving extended Internet protocol statements over theInternet; and means for processing the received extended Internetprotocol statements to control operations associated with a personaldigital assistant (PDA).
 49. The method of claim 48 wherein the extendedInternet protocol statements are extended Hyper Text Transport Protocol(HTTP) statements.
 50. The method of claim 48 wherein the extendedInternet protocol statements are extended Hyper Text Markup Language(HTML) command statements.
 51. A method for supporting communicationbetween a Web server and a personal digital assistant (PDA) over theInternet comprising: processing extended Internet protocol statements ata Web server communicatively coupled to the Internet; communicativelycoupling a personal digital assistant (PDA) to the Internet; andprocessing extended Internet protocol statements with a client programso that the personal digital assistant (PDA) may communicate with theWeb server.
 52. A method for processing extended Internet protocolstatements so a personal digital assistant (PDA) may communicate with aWeb server over the Internet comprising: receiving extended Internetprotocol statements over the Internet; and processing the receivedextended Internet statements to control an operation associated with apersonal digital assistant (PDA).
 53. The method of claim 52 wherein theextended Internet protocol statements are extended Hyper Text TransportProtocol (HTTP) statements.
 54. The method of claim 52 wherein theextended Internet protocol statements are extended Hyper Text MarkupLanguage (HTML) command statements.